It is known in the prior art to provide simulation systems for users distributed geographically relative to each other, potentially thousands of miles apart, with communications between the various users being transmitted over a network, such as the Internet. In these systems, each user normally has a simulation station where the user can see on a screen, a head-mounted display, or other display device, that user's view of a shared virtual environment based on his virtual position in it. The displayed scene is video prepared by an image generator at the simulation station that renders serial frames of video using changing scene data that defines the visible objects in the simulated environment in real-time. The user also can interact with and affect the virtual environment, as with simulated cockpit controls in an aircraft simulator, simulated weapons systems, or other interface mechanisms known in the art, and his interactions that change the scenery can be seen by him and all the other users.
In the armed forces, Distributed Interactive Simulations (DIS) are recognized as being essential for training, system acquisition and test and evaluation. DIS may also be employed in non-military simulation applications such as, e.g., simulations for air traffic control, airplane crash, traffic, land use, environmental, natural disaster, videogames (networked multiplayer video games) and the like. Within the U.S. Department of Defense, key components of DIS include high-fidelity computer-simulated individual entities (tanks, trucks, aircraft, etc.), interactions among entities hosted on different computers through network messages, and support for Human In Loop (HIL) interactions.
Using DIS, it is possible to create large-scale virtual representations of real operational environments that are inexpensive enough to be used repeatedly. Accordingly, a set of DIS protocols were promulgated by the IEEE in 1995 and became the basis for much of the current generation of networked simulations.
Modular Semi-Automated Forces (“ModSAF”) is an example of the implementation and use of the DIS protocol in the armed forces for cost-effective training. ModSAF generally runs using a collection of workstations communicating over a network, typically a LAN. Each workstation is responsible for simulating a predetermined number of entities, or simulated objects. These computer-generated Semi-Automated Forces (“SAF”) are intended to mimic realistically the behaviors of opposing forces or support forces within an exercise. The entity and environment models employed are typically quite detailed and the individual simulators can interact by exchanging data using a messaging protocol, the basic unit of which is referred to as a Protocol Data Units (PDUs). PDUs are used in ModSAF to describe the state of individual entities, weapons firing, detonations, environmental phenomena, command and control orders, etc.
In standard ModSAF, the PDUs are sent as UDP datagrams, which is an unreliable message-delivery mechanism, and therefore each entity state PDU typically contains a complete summary of the vehicle's current state. PDUs are transmitted/retransmitted at frequent, regular “heartbeat” intervals to compensate for dropped data packets. In using such a system, assurance that each simulator receives and responds to all PDUs from all other simulators is extremely difficult, if not impossible, as the number of simulators and simulated entities increases due to the avalanche of communication/network traffic that results from dynamically moving entities continually updating their state. Human-In-Loop (HIL) entities tend to complicate matters even further given their interactive and inherently unpredictable behavior.
A primary problem encountered in such distributed systems is that of latency, meaning communications delay between the transmission from a remote site of data affecting the scene and the reception and display of that data at a user's station. Latency depends on distance and the quality of the communications links, and can commonly be 200 milliseconds (a fifth of a second) or more. The consequence of latency in multi-user situations is that the actions of a remote user do not affect the scene viewed by the local user immediately, and this can result in inconsistencies in the views seen by the users in the distributed system.
To try to reduce some of the effects of latency, prior art systems have used a kinematics approach in which, when information relating to position and movement of a virtual object is received, it is checked for a time-stamp indicative of when precisely in system-time the data was produced. The movement of the affected object is then simply linearly projected or extrapolated to an estimate of its current position, based on its position and velocity defined by the most recent data available, together with a Δt of the time-stamp from the current time, indicating the age of the data in system-time terms.
Linear projections of this type do not accurately extrapolate the real position of objects under a number of circumstances, and in addition to the positional errors associated with a pure linear projection of the location of the object, it is also possible that behavior of the object will be unrealistic if it is projected to a point that it could not reach in reality, such as, for example, when the position of a moving person or vehicle is extrapolated to the other side of a solid wall, making it appear that the person or vehicle actually went through the wall.
Furthermore, especially in military simulation-based training, discrepancies between various users' views of the simulated world can compromise principles of training, notably “fair fight” requirements. “Fair Fight” is a term that means no combatant has an unfair advantage over another due to differences in each participant's representation of the world. Differences in the viewed scenery of the participants can afford such an advantage to one user or another.
In addition, simulators for vehicles, especially aircraft, are usually modeled to run scripts when certain events occur to the user's ownship, such as when damage is done to the vehicle in combat. As an example, in a helicopter simulation, if a blade of the helicopter is shot at and it breaks off, the simulator normally initiates a damaged-vehicle script that is usually limited to a single type of damage scenario, and does not provide the realism of allowing a wide variety of effects for the various types of damage that may be done to the aircraft. These limitations reduce realism and also lessen to a degree the training value of the simulation.